This invention relates to data generation in a testing phase when an enterprise system is replaced.
When an enterprise system is replaced, actual data that is stored in a database (DB) of an existing system is migrated to a new system to be used. Thus, in a testing phase, testing needs to be conducted for actual data in the existing system. However, in recent years, there have been many cases in which actual data cannot be used until execution of the migration due to an increased level of security requirements. In such cases, a software engineer creates testing data based on existing written specifications and conducts testing. However, for example, the existing written specifications may not be updated to cause a difference in specification from the actual data, or the software engineer may make a mistake in designing the testing data, with the result that the software engineer may create testing data that has a difference in characteristic from the actual data. Accordingly, a bug may not be detected in the testing phase due to the difference in characteristic between the testing data and the actual data, to thereby cause a failure after execution of the migration.
There is known JP 2001-256076 A as the related art of this technical field. In JP 2001-256076 A, there is a disclosure of “extracting data characteristics of each column by performing statistical analysis on production DB data and generating test DB data based on the extracted data characteristics”.
With the technology of JP 2001-256076 A, it is possible to generate test DB data in units of tables based on the data characteristics of each column. However, in an actual enterprise system, columns and tables have numerous dependencies, and those characteristics cannot be grasped with use of the data characteristics of each column alone. In particular, in an enterprise system, performance testing needs to be conducted with test DB data that has reflected dependencies between columns or tables because DB accesses for searching or updating a plurality of tables or columns are made numerous times. In order to reflect those dependencies, some approaches are conceivable, such as directly correcting the generated test DB data by a user or developing a separate program for reflecting dependencies between columns in the test DB data. However, those approaches impose a high workload on the user. Further, the data characteristics of each column may be different from those of a production DB due to the user correction or the separate program.